Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

.github/workflows/test.yml (1)

54-56: 💤 Low value

Consider breaking the verification script into multiple lines for readability.

The Node script on line 55 is quite long and hard to read. Consider using a multi-line format or extracting it to a helper script file.

♻️ Suggested improvement for readability

       - name: Verify Chrome
-        run: node -e "const fs = require('node:fs'); const puppeteer = require('puppeteer'); const executablePath = puppeteer.executablePath(); fs.accessSync(executablePath); console.log(executablePath);"
+        run: |
+          node -e "
+            const fs = require('node:fs');
+            const puppeteer = require('puppeteer');
+            const executablePath = puppeteer.executablePath();
+            fs.accessSync(executablePath);
+            console.log(executablePath);
+          "

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/test.yml around lines 54 - 56, The "Verify Chrome" GH
Actions step embeds a long single-line Node command that hurts readability;
refactor the step by replacing the inline one-liner with either a multi-line run
block using a heredoc or by extracting the script to a helper file (e.g.,
scripts/verify-chrome.js) and invoking node on it; locate the step titled
"Verify Chrome" and update the run content that currently calls
puppeteer.executablePath(), fs.accessSync and console.log to a clearer
multi-line script or external file and ensure the step still calls node with the
new script path.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

.github/workflows/test.yml (1)

26-30: ⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if the specified Chrome paths would exist on GitHub runners
# This helps validate the assumption about Chrome installation locations

echo "=== Checking for Chrome/Chromium installation documentation ==="
echo "Note: This check runs in the CodeRabbit sandbox, not on actual GitHub runners"
echo ""
echo "For Ubuntu runners, common Chrome paths:"
echo "  - /usr/bin/google-chrome"
echo "  - /usr/bin/chromium-browser"
echo ""
echo "For Windows runners, common Chrome paths:"
echo "  - C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe"
echo "  - C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"

Repository: rstackjs/rspack-dev-server

Length of output: 476

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Locate the workflow file
ls -la .github/workflows/test.yml

# Show the relevant section around lines 26-30 with a bit of context
nl -ba .github/workflows/test.yml | sed -n '1,120p'

Repository: rstackjs/rspack-dev-server

Length of output: 207

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "---- Workflow: .github/workflows/test.yml (with line numbers) ----"
# Use cat -n since nl isn't available
cat -n .github/workflows/test.yml | sed -n '1,120p'
echo "---- tail ----"
cat -n .github/workflows/test.yml | tail -n 60

Repository: rstackjs/rspack-dev-server

Length of output: 4935

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Search where Puppeteer executable path is read/used
rg -n "PUPPETEER_EXECUTABLE_PATH|executablePath|PUPPETEER_SKIP_DOWNLOAD" -S .

Repository: rstackjs/rspack-dev-server

Length of output: 52

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

rg -n "puppeteer" -S .

Repository: rstackjs/rspack-dev-server

Length of output: 1620

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "---- tests/helpers/run-browser.js ----"
sed -n '1,120p' tests/helpers/run-browser.js
echo
echo "---- tests/helpers/puppeteer-constants.js ----"
sed -n '1,200p' tests/helpers/puppeteer-constants.js

Repository: rstackjs/rspack-dev-server

Length of output: 3775

---

🌐 Web query:

Puppeteer PUPPETEER_EXECUTABLE_PATH environment variable usage

💡 Result:

The PUPPETEER_EXECUTABLE_PATH environment variable is used to override the default browser executable that Puppeteer launches [1]. By setting this variable, you can instruct Puppeteer to use a specific Chrome, Chromium, or other browser installation instead of the one it automatically downloads and manages [2][3]. Key points regarding its usage: - Functionality: When set, this variable provides the default value for the executablePath option in puppeteer.launch if no explicit path is provided in the configuration object [1][4]. - Configuration Priority: Environment variables generally override settings defined in Puppeteer configuration files [2]. - Important Warning: Puppeteer is only guaranteed to work with the specific version of the browser it bundles [5][4]. Using a custom executable via PUPPETEER_EXECUTABLE_PATH is supported but is used at your own risk, as API incompatibilities may occur [5][3]. - Common Use Case: This variable is frequently used in Docker environments or CI/CD pipelines where a pre-installed browser (like a system-level chromium-browser package) is already present, allowing users to skip the Puppeteer browser download process entirely (often paired with PUPPETEER_SKIP_DOWNLOAD=true) [6]. You can set this variable in your shell or environment: export PUPPETEER_EXECUTABLE_PATH=/path/to/your/browser/executable [3] Note: Puppeteer-core ignores environment variables, so this specific variable will not have an effect when using that package [2].

Citations:

• 1: https://github.com/puppeteer/puppeteer/blob/main/docs/api/puppeteer.configuration.md
• 2: https://pptr.dev/guides/configuration
• 3: https://stackoverflow.com/questions/57305779/pupeteer-how-to-specify-chromium-path-on-linux
• 4: https://github.com/puppeteer/puppeteer/blob/v6.0.0/docs/api.md
• 5: https://github.com/puppeteer/puppeteer/blob/main/docs/api/puppeteer.launchoptions.md
• 6: https://pptr.dev/troubleshooting

---

🌐 Web query:

GitHub Actions ubuntu-latest path /usr/bin/google-chrome

💡 Result:

On the standard GitHub Actions ubuntu-latest runner image, Google Chrome is pre-installed at /usr/bin/google-chrome [1]. Key points regarding Google Chrome and its path in GitHub Actions: 1. Default Installation: The standard GitHub-hosted Ubuntu runner image comes with Google Chrome pre-installed as part of its software suite [2][3]. The executable is typically located at /usr/bin/google-chrome, which is a symbolic link managed by the system's update-alternatives [1]. 2. Environment Variables: You can often reference the path using the CHROME_BIN environment variable, which is frequently used by testing frameworks to locate the browser [1][4]. 3. Version Management: While the runner comes with a default version, it is updated periodically with the runner image itself [2][5]. Because these updates are controlled by GitHub and can occasionally introduce regressions or changes, many production workflows pin their Chrome version using actions like browser-actions/setup-chrome to ensure consistency [4][3]. 4. Troubleshooting: If you need a specific version, or if you encounter issues with the pre-installed system browser, it is standard practice to use a setup action. These actions will install the desired version of Chrome and provide an output variable (often named chrome-path) to tell your workflow exactly where the new binary is located, ensuring you do not accidentally target the default /usr/bin/google-chrome [6][4][3].

Citations:

• 1: https://stackoverflow.com/questions/76409431/github-workflow-to-install-chromedriver-based-on-chrome-version
• 2: https://github.com/actions/runner-images/releases/tag/ubuntu24/20260413.86
• 3: https://medium.com/@vikashlb/installing-chrome-in-github-runners-with-browser-actions-setup-chrome-81d2b02833b6
• 4: actions/runner-images#14169
• 5: actions/runner-images#10726
• 6: https://github.com/marketplace/actions/setup-chrome

---

🌐 Web query:

GitHub Actions windows-latest path C:\Program Files\Google\Chrome\Application\chrome.exe

💡 Result:

On GitHub Actions windows-latest runners, there is no guaranteed or static path for chrome.exe [1][2]. While Google Chrome is pre-installed on these images, relying on a hardcoded path like C:\Program Files\Google\Chrome\Application\chrome.exe is considered bad practice because the installation directory and the existence of the browser on the runner image are subject to change by GitHub [1][3]. To reliably use Chrome in a GitHub Actions workflow, it is recommended to use a dedicated action to set up the browser, which ensures the correct version is installed and provides the exact binary path [4][5]. Recommended Approaches: 1. Use a Setup Action (Recommended): Use actions like browser-actions/setup-chrome or step-security/setup-chrome. These actions handle the installation and provide an output variable for the executable path [4][3][5]. Example using step-security/setup-chrome: steps: - uses: step-security/setup-chrome@v2 id: setup-chrome - run: | ${{ steps.setup-chrome.outputs.chrome-path }} --version 2. Locating the Binary (If Pre-installed): If you must use the pre-installed version, avoid hardcoding paths. You can locate the executable dynamically using PowerShell within your workflow: run: | $chromePath = Get-ChildItem -Path "C:\Program Files\Google\Chrome\Application\chrome.exe" -ErrorAction SilentlyContinue if ($chromePath) { & $chromePath.FullName --version } else { Write-Error "Chrome not found at expected path." } Note: GitHub maintains the runner-images repository where software on windows-latest is defined [6][7]. As of mid-2026, these runners include Google Chrome, but installation details are managed via automation scripts and can vary based on image updates [8][2]. Always refer to the official runner-images documentation or rely on setup actions for stability [4][6].

Citations:

• 1: actions/runner-images#8114
• 2: actions/runner-images#11095
• 3: https://github.com/browser-actions/setup-chrome/releases
• 4: https://github.com/step-security/setup-chrome
• 5: https://browser-actions.dev/setup-chrome/
• 6: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md
• 7: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-VS2026-Readme.md
• 8: https://github.com/actions/runner-images/releases/tag/win25-vs2026/20260525.121

---

Harden Chrome executable path setup for Puppeteer in CI

In .github/workflows/test.yml (lines 26-35), the workflow hardcodes puppeteer-executable-path and sets PUPPETEER_EXECUTABLE_PATH, but the test code calls puppeteer.launch() without an executablePath, so it relies on that env var. Since PUPPETEER_SKIP_DOWNLOAD: true, a moved/nonexistent Chrome binary will break tests.

• Ubuntu/runner updates can still relocate Chrome (/usr/bin/google-chrome is not guaranteed forever).
• windows-latest does not have a stable, guaranteed Chrome path, so the hardcoded C:\Program Files\Google\Chrome\Application\chrome.exe is fragile.
• Add a Chrome setup step (e.g., browser-actions/setup-chrome / step-security/setup-chrome) and set PUPPETEER_EXECUTABLE_PATH from the action’s chrome-path output, or dynamically locate Chrome before running tests.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/test.yml around lines 26 - 30, The workflow hardcodes
puppeteer-executable-path and exports PUPPETEER_EXECUTABLE_PATH while tests call
puppeteer.launch() (relying on that env var) and PUPPETEER_SKIP_DOWNLOAD is
true, which is fragile across runners; update .github/workflows/test.yml to
install or locate Chrome via a setup action (e.g., browser-actions/setup-chrome
or step-security/setup-chrome) before tests, capture the action output
(chrome-path) and set PUPPETEER_EXECUTABLE_PATH from that output instead of
hardcoding, or add a step that dynamically discovers the Chrome binary and
exports PUPPETEER_EXECUTABLE_PATH so puppeteer.launch() finds a valid
executable.